<?php
/**
 * <https://y.st./>
 * Copyright © 2019 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => 'Unified levelling mechanics',
	'takedown' => '2017-11-01',
	'<{body}>' => <<<END
<img src="/img/CC_BY-SA_4.0/y.st./weblog/2019/07/30.jpg" alt="Morning glories growing out of the sidewalk" class="framed-centred-image" width="800" height="480"/>
<section id="dreams">
	<h2>Dream journal</h2>
	<p>
		I dreamed I was at home, mostly nude.
		There was nothing too odd about that; I don&apos;t wear clothing when there&apos;s no one around to care.
		My bedroom wasn&apos;t quite set up like my real-world bedroom, but I still had a large mirror.
		I also had an actual bed though, and not just a mattress on the floor.
		I could see my labia in the mirror&apos;s reflection.
		Someone came into the room, so I ducked down behind the bed.
		I didn&apos;t want to be seen nude.
		Oddly, my reflection, stayed in place, which was no good.
		The person wasn&apos;t in a position to see me directly, and I&apos;d actually been trying to move my reflection out of visibility by moving my actual body out of the reflected line of sight.
	</p>
	<p>
		What an odd dream though.
		Ignoring the fact that my sleeping brain doesn&apos;t seem to be able to properly compute where reflections should be in real time, I don&apos;t even have a labia.
		I may not be a man, but I&apos;m still a male.
	</p>
</section>
<section id="diet">
	<h2>Dietary intake</h2>
	<p>
		For breakfast, I had 75 grams of cereal and 100 grams of soy milk.
		For lunch, I had a peanut butter and jelly sandwich.
		For dinner, I had 500 grams of potato, onion, and pickle stew.
		It would have come out better without the pickles, but I was thinking about the pickle soup recipe I&apos;d tried and thinking maybe pickles in a soup/stew would come out better this time.
		They didn&apos;t.
		Anyway, I forgot about my shrivelling potatoes for a while, and I really need to get back to them before they become completely unusable.
	</p>
</section>
<section id="drudgery">
	<h2>Drudgery</h2>
	<p>
		My discussion post for the day:
	</p>
	<blockquote>
		<p>
			You make some great points that I hadn&apos;t considered.
			It does keep things tidier to separate form from functionality, and like you said, if you&apos;re on a development team, having separate groups working in separate files can make life easier.
			The design team won&apos;t mess up work done by the programming team and vice versa.
		</p>
	</blockquote>
	<p>
		Someone also commented on my post, telling me I&apos;d forgotten a bunch of stuff about $a[XML].
		I think not!
		I likely know more about $a[XML] than most of the other students because I actually use it on a daily basis.
		However, the discussion topic wasn&apos;t $a[XML], so that knowledge was irrelevant.
		The topic was the separation of Java logical code from Android application $a[XML] layout code.
		Android application $a[XML] layout code is a very specific subset of $a[XML], and the fact that $a[XML] is used in office automation, for example, has nothing to do with what we&apos;re supposed to be talking about.
		My response:
	</p>
	<blockquote>
		<p>
			Everything you said about $a[XML] is completely true, but it&apos;s also completely irrelevant to the discussion topic.
			The discussion topic asks about the benefits and drawbacks of using $a[XML] for Android application layouts instead of embedding the layouts in the Java code.
			$a[XML]&apos;s use for other purposes, such as the many places it can be found on the Web, has nothing to do with its use in defining Android application layouts.
			Like you said, the scope of $a[XML] is very broad.
			However, the scope of Android $a[XML] application layouts is not.
		</p>
	</blockquote>
</section>
<section id="Minetest">
	<h2>Minetest</h2>
	<img src="/img/CC_BY-SA_3.0/minetest.net./weblog/2019/07/30.png" alt="So close to level-up!" class="framed-centred-image" width="1024" height="600"/>
	<p>
		I&apos;ve been toying with the name <code>liblevelup</code> for at least a week now.
		It seems like a more fitting name for <code>minestats</code> and what it has become.
		However, I haven&apos;t wanted to actually change the name because of the compatibility problems that would cause.
		And <code>minestats</code> still provides its stat-related functions, so I&apos;ve left the name.
		the underlying mechanics were still very stat-centric, despite my efforts to unify the stats using the unified levelling system.
	</p>
	<p>
		Today though, I figured out how to fix the biggest problem in the unification of the levelling system: players&apos; levels are still handled in a very segmented way.
		You might gain a level if you mined two coral skeletons, but have to mine thousands of coal before you gain a level.
		And mining one coral skeleton would have no impact on the number of coal you need to mine to gain a level.
		Internally, there are literally separate levels for each element, and they get added together to form the full level.
		What I&apos;ve decided to do is not to round levels down until <strong>*after*</strong> adding them together.
		That way, partial levels in one element do affect the total when added with partial levels toward another element, and levelling will appear more fluid to the player, and not disjointed like they are now.
	</p>
	<p>
		I&apos;m going to need to overhaul much of the $a[API], and in the process, I think I&apos;m going to deprecate the whole thing.
		Pretty much all methods directly relating stats and not levels to progression will be put in the scrap heap.
		It&apos;s a perfect time to change the name even.
		The old $a[API] methods will still be kept for at least two years to give anyone using <code>minestats</code> (which let&apos;s be honest, is probably no one) time to update their mods, but <code>minestats</code> has reached its end.
		It&apos;ll be replaced by <code>liblevelup</code>: the player progression library.
		<code>minestats</code> was always intended to provide a sense of progression, but in my lack of experience, I failed to shape it to properly do that.
		With this overhaul, I hope to fix my mistakes and get <code>liblevelup</code> to live up to what I&apos;ve always hoped <code>minestats</code> could be.
		I had time after work to do much of the overhaul.
		I didn&apos;t completely throw away as much as I thought I would, as the stuff that queries stats is still useful for building stat-related mods, but some code tried and failed to tie progression to stats in a linear way, and that stuff is being deprecated.
		And I still want to rename some of the methods to be less stupid, and implement some argument order standards.
		I&apos;ve been looking at previous methods when I define new methods with similar arguments, so I think the $a[API] is mostly consistent in that regard.
		I might not need to change a single function&apos;s argument order.
		If there are any oddball ones though, I want to get those fixed.
		I also want to formalise what the argument order should be, so I can better remember it.
		I often have to reread the source code just to use remember the order of the arguments, and I shouldn&apos;t have to do that.
		I should be able to just know that the player name argument always comes first.
		(I&apos;m pretty sure it does, for all $a[API] functions that take a player name, but I always think that maybe material names come before player names for some reason.)
	</p>
	<p>
		With how close I am to levelling up, it seems that all I&apos;d have to mine is one item, so long as it&apos;s an item I&apos;ve never mined before.
		I&apos;m assuming I didn&apos;t botch things up really badly, though given the amount of debugging I already had to do, there&apos;s a good chance that I did.
		Mostly, the new outputs seem reasonable though.
		I think.
		And given the levelling curve, it makes sense that something I&apos;ve never mined before would be worth so much more than something I&apos;ve mined plenty of.
		It&apos;s actually one of the intended mechanics it took me forever to get right; one of the purposes of having the levelling curve at all.
		I ran a test world too, and it gave the expected values before mining anything.
		<strong>*After*</strong> mining though, I found an interesting quirk.
		Due to the levelling curve, things you haven&apos;t mined are worth more than things you have.
		That&apos;s a given.
		But it&apos;s so much so that you can mine seven items - far less than the 99 it would take if you mined only a single type of item - and still gain your first level, provided all seven items that you mine are different elements.
		The greater the variety, the less you need to mine.
		Wow.
		The theory checks out though, based on how exponents work, so this isn&apos;t a bug, though that doesn&apos;t mean there aren&apos;t bugs elsewhere.
		I&apos;ve removed direct reverences to the levels of individual elements at all from the levelling menu, too.
		I mean, partly, that&apos;s because the methods needed to query levels of individual elements is deprecated now.
		Getting drop counts isn&apos;t, but trying to get curve data for a single element very much is.
		But also, I feel freer now.
		I wanted so much to have a mushroom farm as soon as possible because it&apos;ll take so long to reach the maximum spore levels, and I wanted to get started on that.
		Actually farming the mushrooms has gotten rather boring though.
		Not having to look at my mushroom levels compared to my other levels, I no longer have the incentive to try to keep my mushroom levels as my top levels, dropping everything else and head back to the mushroom garden when other levels get too high.
		I can just play the game now.
		Again, I think this is better.
		Pushing to keep farming and mining is great, but pushing to farm or mine a particular drop makes the game a bit of a drag.
		I was sucking some of the fun out of the game, and now, I don&apos;t think that I am any more.
	</p>
</section>
END
);
